src/main/java/com/jangburich/domain/store/domain/StoreTeamResponseDTO.java (2)

3-3: 사용하지 않는 import 문이 있습니다.

Team 클래스를 import 하고 있으나 코드 내에서 사용되지 않고 있습니다.

다음과 같이 수정해주세요:

-import com.jangburich.domain.team.domain.Team;

---

17-24: @QueryProjection 생성자에 유효성 검증이 필요합니다.

데이터베이스에서 조회한 결과를 매핑할 때 null 체크나 유효성 검증이 없습니다.

다음과 같이 개선해보세요:

 @QueryProjection
 public StoreTeamResponseDTO(Long id, Integer point, Long teamId, String teamName, Long storeId) {
+    if (id == null || teamId == null || storeId == null) {
+        throw new IllegalArgumentException("필수 ID 값이 누락되었습니다");
+    }
+    if (teamName == null || teamName.trim().isEmpty()) {
+        throw new IllegalArgumentException("팀 이름은 필수입니다");
+    }
     this.id = id;
     this.point = point;
     this.teamId = teamId;
     this.teamName = teamName;
     this.storeId = storeId;
 }

src/main/java/com/jangburich/domain/payment/domain/TeamChargeHistoryResponse.java (2)

7-13: 레코드 클래스 설계가 잘 되었습니다.

불변 데이터를 위한 레코드 사용이 적절하며, 필드들의 명명이 명확합니다. 하지만 필드에 대한 유효성 검증이 없습니다.

다음과 같은 검증 로직 추가를 고려해보세요:

@Builder
public record TeamChargeHistoryResponse(
    Long id,
    String transactionId,
    Integer paymentAmount,
    PaymentChargeStatus paymentChargeStatus
) {
+    public TeamChargeHistoryResponse {
+        if (paymentAmount != null && paymentAmount < 0) {
+            throw new IllegalArgumentException("결제 금액은 음수일 수 없습니다.");
+        }
+        if (transactionId != null && transactionId.isBlank()) {
+            throw new IllegalArgumentException("거래 ID는 비어있을 수 없습니다.");
+        }
+    }

---

14-21: QueryProjection 생성자가 적절히 구현되었습니다.

QueryDSL 프로젝션을 위한 생성자가 잘 구현되어 있습니다. 하지만 Javadoc 문서화가 누락되어 있습니다.

다음과 같이 Javadoc을 추가하는 것을 추천드립니다:

+    /**
+     * QueryDSL 프로젝션을 위한 생성자입니다.
+     *
+     * @param id 팀 충전 내역 ID
+     * @param transactionId 거래 ID
+     * @param paymentAmount 결제 금액
+     * @param paymentChargeStatus 결제 상태
+     */
    @QueryProjection
    public TeamChargeHistoryResponse(Long id, String transactionId, Integer paymentAmount,
        PaymentChargeStatus paymentChargeStatus) {

src/main/java/com/jangburich/domain/store/domain/dto/response/PaymentGroupDetailResponse.java (1)

15-15: 클래스 문서화가 필요합니다

클래스의 목적과 사용법에 대한 문서화가 없습니다.

다음과 같이 Javadoc을 추가하는 것을 추천드립니다:

+/**
+ * 결제 그룹의 상세 정보를 담는 응답 DTO입니다.
+ * <p>
+ * 이 클래스는 팀 정보, 포인트 정보, 팀장 정보 및 결제 내역을 포함합니다.
+ * 모든 필드는 불변이며, 객체 생성은 {@link #create} 팩토리 메서드를 통해서만 가능합니다.
+ */
 public class PaymentGroupDetailResponse {

src/main/java/com/jangburich/domain/store/domain/StoreTeam.java (1)

40-41: 포인트 필드에 대한 문서화가 필요합니다.

remainPoint 필드의 용도와 point 필드와의 차이점을 명확히 하기 위해 Javadoc 문서화를 추가해 주세요.

+/**
+ * 사용 가능한 잔여 포인트를 나타냅니다.
+ * point는 총 적립된 포인트를, remainPoint는 실제 사용 가능한 포인트를 추적합니다.
+ */
 @Column(name = "remain_point")
 private Integer remainPoint;

src/main/java/com/jangburich/domain/payment/application/KakaopayService.java (1)

Line range hint 126-127: 예외 처리 개선 필요

TeamChargeHistory를 찾지 못했을 때 발생하는 raw NullPointerException은 적절한 커스텀 예외로 대체되어야 합니다. 이는 다음과 같은 이유로 중요합니다:

1. 명확한 에러 메시지 제공
2. 일관된 예외 처리 패턴 유지
3. 디버깅 용이성 향상

다음과 같이 수정을 제안합니다:

- .orElseThrow(() -> new NullPointerException());
+ .orElseThrow(() -> new DefaultNullPointerException(ErrorCode.TEAM_CHARGE_HISTORY_NOT_FOUND));

ErrorCode에 적절한 상수를 추가해주세요:

TEAM_CHARGE_HISTORY_NOT_FOUND("결제 내역을 찾을 수 없습니다.")

src/main/java/com/jangburich/domain/store/domain/service/StoreService.java (4)

156-167: userId 대신 Authentication 객체 사용을 권장드립니다.

getPaymentGroup 메서드에서는 String userId를 파라미터로 받고 있습니다. 다른 메서드들(searchByCategory, searchStores)에서는 Authentication 객체를 받아 AuthenticationParser를 통해 userId를 추출하고 있습니다. 일관성을 위해 Authentication 객체를 받아 처리하는 것을 추천합니다.

---

190-213: 중복 코드의 리팩토링을 제안합니다.

getPaymentGroupDetail 메서드에서 User, Owner, Store를 조회하는 로직이 앞서 구현된 메서드들과 중복됩니다. 해당 부분을 별도의 공통 메서드로 추출하여 코드 중복을 줄이고 유지보수성을 높일 수 있습니다.

---

209-210: 변수 명칭을 더 명확하게 변경해주세요.

chargeHistoryRepositoryAllByTeam 변수명은 다소 길고 의미 전달이 어려울 수 있습니다. teamChargeHistories와 같이 보다 직관적인 이름으로 변경하면 코드를 이해하기 쉽습니다.

---

트랜잭션 어노테이션 적용이 필요한 메서드가 있습니다.

데이터 변경 작업을 분석한 결과, 다음과 같이 트랜잭션 어노테이션을 수정해야 합니다:

• createAdditionalInfo 메서드: 여러 set 작업과 save 작업이 포함되어 있으므로 @Transactional 어노테이션이 필요합니다.
• createStore, updateStore 메서드: 현재 올바르게 @Transactional이 적용되어 있습니다.
• 나머지 조회 메서드들(getStoreInfo, getPaymentGroup, searchByCategory, searchStores, getPaymentGroupDetail): 읽기 전용 트랜잭션으로 처리하는 것이 좋습니다. @Transactional(readOnly = true) 적용을 권장합니다.

🔗 Analysis chain

Line range hint 50-213: 트랜잭션 범위를 재검토해주세요.

일부 메서드에만 @Transactional 어노테이션이 적용되어 있습니다. 데이터 변경이 없는 조회 메서드에서도 필요한 경우 트랜잭션을 적용하거나, 불필요한 곳에서는 제거하여 트랜잭션 경계를 명확히 설정하는 것이 좋습니다.

다음 스크립트를 실행하여 각 메서드의 트랜잭션 어노테이션 적용 여부를 확인할 수 있습니다:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: `@Transactional` 어노테이션이 올바르게 적용되었는지 확인합니다.

# Test: 메서드별로 `@Transactional` 사용 여부를 확인합니다.
ast-grep --pattern $'@Transactional\n$_\npublic $_($_) {\n$$$}' src/main/java/com/jangburich/domain/store/domain/service/StoreService.java

Length of output: 136

---

Script:

#!/bin/bash
# Let's try a different approach to check the methods and their transaction annotations

# First, let's see all public methods in the service
echo "=== All public methods ==="
rg "public.*\{" src/main/java/com/jangburich/domain/store/domain/service/StoreService.java

# Then, let's check which ones have @Transactional
echo -e "\n=== Methods with @Transactional ==="
rg -B1 "public.*\{" src/main/java/com/jangburich/domain/store/domain/service/StoreService.java | grep -B1 "public"

# Let's also check if there are any repository save/update operations
echo -e "\n=== Repository operations ==="
rg "repository\.(save|update|delete)" src/main/java/com/jangburich/domain/store/domain/service/StoreService.java

Length of output: 1602

---

Script:

#!/bin/bash
# Let's check for repository operations with a broader pattern and look for data modifications
echo "=== Repository save operations ==="
rg "storeRepository\.save" src/main/java/com/jangburich/domain/store/domain/service/StoreService.java -B1 -A1

echo -e "\n=== Store modifications ==="
rg "store\.set" src/main/java/com/jangburich/domain/store/domain/service/StoreService.java -B1 -A1

# Let's also check for any other repository methods that might modify data
echo -e "\n=== All repository method calls ==="
rg "Repository\." src/main/java/com/jangburich/domain/store/domain/service/StoreService.java

Length of output: 4569

Configuration used: .coderabbit.yaml
Review profile: CHILL

#!/bin/bash
# PaymentChargeStatus 열거형 정의를 확인
ast-grep --pattern 'enum PaymentChargeStatus {
  $$$
}'

# PaymentChargeStatus 사용처 확인
rg -A 5 'PaymentChargeStatus'

#!/bin/bash
# TeamChargeHistoryResponse 클래스에서 매핑 관련 코드 확인
ast-grep --pattern 'record TeamChargeHistoryResponse($$$) {
  $$$
}'

# 매핑 구현이 있는지 확인
rg -A 5 "TeamChargeHistory.*TeamChargeHistoryResponse"

#!/bin/bash
# 1. TeamChargeHistoryResponse 클래스 파일 찾기
fd TeamChargeHistoryResponse

# 2. TeamChargeHistory 엔티티 클래스 찾기
fd TeamChargeHistory

# 3. Repository 클래스에서 관련 쿼리나 매핑 확인
rg -A 5 "@Query.*TeamChargeHistoryResponse"

# 4. 프로젝트 내의 모든 TeamChargeHistoryResponse 사용 검색
rg "TeamChargeHistoryResponse"

#!/bin/bash
# TeamChargeHistoryResponse 레코드의 구현 확인
cat src/main/java/com/jangburich/domain/payment/domain/TeamChargeHistoryResponse.java

# TeamChargeHistory 엔티티 구현 확인
cat src/main/java/com/jangburich/domain/payment/domain/TeamChargeHistory.java

# Repository 구현체 확인
fd -e java "TeamChargeHistoryRepositoryImpl"

#!/bin/bash
# StoreTeam 클래스에서 addPoint와 addRemainPoint 메서드의 구현을 확인

ast-grep --pattern $'class StoreTeam {
  $$$
  addPoint($_) {
    $$$
  }
  $$$
  addRemainPoint($_) {
    $$$
  }
  $$$
}'

#!/bin/bash
# Search for StoreTeam class implementation
rg -U "class StoreTeam[\s\S]*?}" -A 10

# Search for addPoint and addRemainPoint method calls or references
rg "addPoint|addRemainPoint" -A 2 -B 2